\section{Comparaci\'on de los m\'etodos usados}

%- Breve comparación de los métodos usados (UP vs Ágil).
%- Comparar “programming in the small" y "programming in the
%large” (diseño OO vs Arquitectura).
%- Conclusiones que sacó el grupo.

\textsl{En esta secci\'on se presentar\'an conclusiones y 
comentarios sobre la aplicaci\'on de los m\'etods de SCRUM y UP, y
por \'ultimo una conclusi\'on final del grupo.}

\vspace*{0.5cm}

Durante la primera parte de la materia tuvimos que enfrentarnos con la
metodolog\'ia SCRUM, y en la segunda parte extendimos lo realizado para
que tuviera un alcance mucho mayor, haciendo una planificaci\'on
usando la metodolog\'ia UP.

\subsection{SCRUM}

El desarrollo de un proyecto con SCRUM lleva a la obtenci\'on de un
producto que est\'a todo el tiempo en desarrollo, que es un sistema
que crece. 
El mismo tiene funcionalidades que se van combinando, generando una
aplicaci\'on con mayores funcionalidades con el tiempo.
Esto nos recuerda la posici\'on de grow en el debate de grow vs build,
presentado por Brooks en el paper \emph{No silver bullet}.

\vspace*{0.3cm}

El desarrollo se divide en muchas etapas cortas, denominadas sprints.
En cada una de ellas, se decide implementar un conjunto de tareas, las
cuales son elegidas por todos los miembros del equipo que est\'a
trabajando en el proyecto.
Esto tiene la ventaja de que es el equipo el que decide qu\'e tareas
piensa poder hacer en la duraci\'on de un sprint. 
Para poder decidir, antes se debi\'o hacer alg\'un tipo de 
estimaci\'on, teniendo en cuenta no s\'olo la dificultad aparente
sino tambi\'en el valor para el proyecto.
Luego el equipo se compromete a llegar con el desarrollo en el tiempo
establecido.
Al finalizar cada sprint, se hace una autocr\'itica del desempeño, que
lleva a un mejor rendimiento en futuros sprints.

\vspace*{0.3cm}

Las tareas surgen de la descomposici\'on de \emph{User Stories}. 
\'Estas detallan lo que cada uno de los interesados en el sistema 
desea hacer (Ej. ``Como desarrollador de este tp deseo que la 
redacci\'on del informe no me lleve m\'as de 6 horas'').
Cada User Story puede descomponerse en una o m\'as tareas.

\vspace*{0.3cm}

Un detalle de esta forma de trabajo es que las tareas de todo el 
proceso de desarrollo pueden ser potencionalmente realizadas por 
cualquier miembro del equpo.
Se supone que el nivel de conocimiento de todos es similar, y bueno.

\subsection{UP}

En UP, los l\'imites, los tiempos, las tareas y los roles que van a 
ser asumidos por cada uno de los miembros del proyecto son fijos y se 
deciden al principio. Esto es distinto a como era en SCRUM, que tiene
menos planificaci\'on.

\vspace*{0.3cm}

El desarrollo se divide en 4 grandes etapas: Inception, Elaboraci\'on,
Construcci\'on y Transici\'on.
Si bien no son excluyentes y pueden convivir, es marcado como una
predomina sobre las dem\'as en cada momento.

\vspace*{0.3cm}

Consideramos que no tenemos los elementos, ni la experiencia suficientes
para poder hacer una comparaci\'on entre ambas metodolog\'ias de
manera equitativa.

\vspace*{0.3cm}

A grandes rasgos, y m\'as como una opini\'on que como conclusi\'on 
fuerte y fundamentada, consideramos que el overhead de UP dado por 
su burocracia, dificulta innecesariamente el desarrollo de la
mayor\'ia de los proyectos de software.
Opinamos esto porque puede ser que retrase demasiado la obtenci\'on de
un prototipo que permita visualizar la aplicaci\'on funcionando,
aunque sea una versi\'on no terminada.

\vspace*{0.3cm}

No obstante, para proyectos con m\'argenes de error m\'as estrictos 
una metodolog\'ia que dedique m\'as tiempo a la planificac\'on 
deber\'ia rendir sus frutos.
La inversi\'on en el overhead de UP parece que podr\'ia producir 
beneficios que la justifiquen.

\subsection{Conclusi\'on breve}

Creemos que ning\'un fanatismo es bueno, y que lo ideal es conocer
diferentes estrategias para poder adaptarse a distintos casos, sabiendo
c\'omo enfrentarlos.
Al momento de decidir, se pueden tener en cuenta las ventajas y
desventajas de cada metodolog\'ia, pudiendo optar por tomar partes de
cada una seg\'un convenga.

